The present invention generally relates to secure elements such as smart cards inserted into portable devices such as mobile phones. The present invention more particularly relates to memory management on smart cards.
Applications or “applets” (in JavaCard) are now available that can be used to provide a wide range of add-on services and features to portable devices. Development of inductive coupling contactless communication techniques, also called NFC techniques (Near Field Communication), changed the field of chip cards, making it possible first to make contactless payment cards, and then, to integrate a secure processor and an NFC controller into mobile phones, to perform secure near field transactions.
FIG. 1 schematically shows a transaction system including a mobile phone HD and a transaction terminal TT. The phone HD comprises for example a main processor BBP also known as a “base-band” processor, a radiocommunication circuit RCT connected to the processor BBP, an NFC controller referenced “NFCC” also connected to the processor BBP by a link B2, an antenna coil AC1 connected to the controller NFCC, and a secure processor SE configured to perform NFC transactions. The phone HD may also comprise another (external) secure processor, a SIM (Subscriber Identity Module) card and a memory card such as a MicroSD (Micro Secure Digital) card.
The processor SE is connected to or in communication with the processor BBP and comprises a central processing unit CPU, and a secure non-volatile internal memory IM storing an operating system and applications or applets. The processor SE is linked to the controller NFCC through a bus B3, for example a SWP (Single Wire Protocol) bus. In practice, the processor SE may be a Universal Integrated Circuit Card (UICC), for example of the mini-SIM or micro-SIM type.
The controller NFCC comprises a contactless front end interface CLF linked to an antenna circuit AC1. In practice, the controller may be integrated into a semiconductor chip, such as the MicroRead® chip commercialized by the Applicant.
The bus B3 linking the processor SE and the controller NFCC is used as physical support for a communication interface, known as a Host Controller Interface (HCI) in the example of SWP. The controller NFCC and the processor SE exchange data via this interface in accordance with a Host Controller Protocol HCP. The interface HCI and the protocol HCP are described in the ETSI TS 102 622 specifications (European Telecommunications Standards Institute), called “Smart Cards; Universal Integrated Circuit Card (UICC); Contactless Front-end (CLF) interface; Host Controller Interface (HCI)”. The protocol HCP specifies the routing of data according to routing channels called “pipes”, through which application data are exchanged during a transaction between the processor SE and the transaction terminal TT.
The terminal TT is for example a cash point, a sales outlet (e.g., ticket machine, food and drink dispenser, . . . ), an automatic paying access control terminal (e.g., subway access terminal, bus payment terminal), or the like. The terminal TT comprises an antenna coil AC2 and is configured to perform a near field transaction with a contactless card or, for example, the processor SE via the controller NFCC by emitting a magnetic field. A transaction comprises the exchange of Application Protocol Data Units (APDU). The application data APDU comprise commands sent by the terminal TT and responses sent by the card or processor SE executing an applet corresponding to the transaction performed by the terminal TT.
When a communication link is established between the processor SE and a terminal such as the terminal TT, the terminal transmits an APDU command SELECT-AID (AID: Applet Identifier) to activate a particular applet in the processor SE. If the applet identified by the command SELECT-AID is present in the processor SE, the applet is activated. Otherwise, the processor SE (the operating system thereof) transmits an APDU response “file not found” or similar, depending on the reason of failure.
Several applications or applets may be stored in the non-volatile memory IM of the smart card processor SE. These applications may relate to payment transactions or provide access to subscription-based services such as transportation services. However, this memory has a limited size. Even if the size of the smart card memory increases with each new generation of smart cards, it may not be sufficient to meet the needs of ever-growing NFC services offered.
In addition, payment and access transactions require that the smart card, and more particularly its memory be secured. This requirement is fulfilled by software and/or hardware countermeasures aiming to prevent various attacks on the card. Software countermeasures may consist of inserting random delays while performing critical operations, and/or counting errors and erasing critical data when the error count exceeds a threshold value, and/or distributing processing of pieces of data to randomly selected elementary operations, and/or performing critical operations several times and comparing the results obtained each time, and/or performing reverse computing of a critical operation and comparing the input data with the data provided by the reverse computing. Such software countermeasures tend to increase the memory size occupied by the applet and operating system code. Hardware countermeasures aim to prevent or detect reverse engineering and/or fault injection, and/or consist in mixing processing circuits and memory. The data stored in the secure memory can be encrypted, which requires circuits for efficiently encrypting the data before they are stored in the memory, and decrypting data read in the memory. Parity bits can be added to each word stored in the memory so as to detect fault injection. Such parity bits require additional memory space and circuits for computing and controlling the values of these bits. Therefore, securing a smartcard tends to increase the size of the memory on chip and the cost of the chip.
In other aspects, even if many applets can be stored in a smart card, a limited number of applets can potentially be executed at a given time. Applet pre-selection may be performed by the user or as a function of geolocalization data, date and time, or other available information. For instance, the user may have preselected an applet within a group such as a payment applet group, for example to select a bank, a bank account or an e-purse, or to select between local and global payment. A transportation service applet may be selected within a group of available transportation applets as a function of geolocalization data. Some applets may also temporarily be deactivated for example due to incompatible protocol parameters or routing table configuration.
Therefore, deactivated applets or applets not available for selection may be removed from the smartcard memory. However, loading and installing applets in a secure smart card is a complex operation that is highly secured. This operation may be performed by an external manager such as a Trusted Service Manager TSM or the card issuer that detains cryptographic keys allowing access to a security domain of the smart card. Therefore, the removal of an applet from the memory of the smartcard is not desirable unless the applet will no longer be needed.
It is therefore desirable to enlarge the storage capacity of a secure processor such as the one integrated into a smartcard when installing new applications or applets without increasing the cost of the processor.